home *** CD-ROM | disk | FTP | other *** search
/ MacFormat 1996 September / macformat-041.iso / mac / Shareware City / Graphics / MacSPD / Sources / README.1st < prev    next >
Encoding:
Text File  |  1995-04-22  |  8.2 KB  |  179 lines  |  [TEXT/MMCC]
  1. SPD 3.6 Enhanced - April 3, 1995
  2. --------------------------------
  3.  
  4. by Alexander Enzmann, w/modifications and additions by Eric Haines
  5.  
  6. This is an updated version (a) of the Standard Procedural Databases (SPD v3.1)
  7. package & library code distributed by Eric Haines.  In addition to supporting
  8. the NFF object data format, the file "lib.c" has been extended to support the
  9. input format of the following renderers:
  10.  
  11.     MTV (i.e. NFF)
  12.     POV-Ray 1.0
  13.     POV-Ray 2.0 to 2.2
  14.     Polyray 1.4 to 1.6
  15.     Vivid 2.0
  16.     QRT 1.5
  17.     Rayshade 4.0.6
  18.     RTrace 8.0.0
  19.     Art 2.3 (from Vort)
  20.     RenderMan RIB
  21.     AutoCAD DXF [object data only]
  22.     Wavefront OBJ format (polygons only)
  23.     RenderWare RWX script file
  24.  
  25.     In addition, there is a program nff2rad.c which converts NFF data to
  26. Radiance format (if anyone feels like folding this code into lib.c, please
  27. do).  Note that this converter is not listed in the makefile since it's
  28. special purpose (and standalone, so it's trivial to compile).
  29.  
  30.     A very rudimentary capability to dump polygons in the PLG format used
  31. by REND386 is also supported.  A very simple DXF reader has also been added.
  32. Its primary purpose was to display simple DXF files to the screen, but it has
  33. the side effect of being able to translate DXF files (only 3DFACE, though)
  34. to any of the above ray tracer file formats.
  35.  
  36.     Similarly, a readobj program is provided which reads Wavefront OBJ
  37. files and converts to other formats.  This program is handy for reading all
  38. those free Viewpoint demo databases on avalon.chinalake.navy.mil and
  39. elsewhere.
  40.  
  41.     Simple display drivers have been included various flavors for the IBM
  42. PC (VGA, Zortech, Gnu C, etc), Apple Macintosh, and Hewlett Packard Starbase.
  43. Drivers are very simple to write:  you just need a display initialization
  44. routine, a display close routine, and a line drawing routine.  For Unix
  45. systems, for example, just copy and fill in unix.c.
  46.  
  47.     Feel free to play with this stuff in whatever manner you choose.  Eric
  48. was kind enough to make the original freely available, and I'm not about to
  49. change that.  Of course this code is provided without any warranty of any
  50. kind, and no assumption of responsibility for any consequences of using it are
  51. made.
  52.  
  53.  
  54. Changes From Original
  55. ---------------------
  56.  
  57. The biggest changes to the original NFF/SPD stuff is in the area of surface
  58. shading attributes.  Since many raytracers support scale values for more
  59. components of the shading model than are present in NFF, these have been
  60. added.  The new components that have to be given in any call to
  61. "lib_output_color" are:  Ka (ambient), Shine (Phong specular), Shine angle
  62. (50% falloff angle for Phong spot, in degrees).
  63.  
  64. The separation of the Phong values from the Ks (specular) value simply
  65. reflects the fact that most renderers don't force you to do both at the same
  66. time (RTrace being an exception).  Using a falloff angle for the Phong
  67. highlight may seem odd to you, but it really is sensible.  Smaller angles mean
  68. smaller highlights.
  69.  
  70. Another change in the call to "lib_output_color" is a parameter that allows
  71. the definition of a texture name.  Many raytracers support named textures, by
  72. using a non-NULL string, you can specify a predefined texture name (these
  73. things are pretty renderer specific).  All of the examples use NULL, which
  74. defaults to plopping the current color into each primitive.
  75.  
  76.  
  77. Other stuff
  78. -----------
  79.  
  80. The original documents have been included (unchanged).  As far as the
  81. documents for each of the raytracers mentioned above, you will have to get
  82. them from their source.  Most of those raytracers are available on Compuserve
  83. (go GRAPHDEV).  I haven't included one with this library.
  84.  
  85. The database generation programs that were supplied with the original SPD
  86. package have been altered slightly to accept values from the command line.
  87. This makes it a little easier to generate outputs of varying complexity, and
  88. for the various renderers.  Typically the order of the command line options
  89. is:
  90.  
  91.     prog [-s size_factor] [-r renderer] [-c|-t]
  92.  
  93. i.e. "balls -s 2 -r 1 > balls.nff" generates a level 2 sphereflake in MTV's
  94. native format (NFF).  The meaning of "size_factor" varies from program to
  95. program, but basically indicates the complexity of the database that will be
  96. generated.  The "renderer" option corresponds to the definitions in "def.h"
  97. for the various supported renderers.  (i.e. 0 means display on screen, 2
  98. means POV-Ray 1.0, ...)  The [-c|-t] determines the output format, -c means
  99. output curved object primitives, -t means output polygonal patches in a mesh
  100. for curved surfaces.  By default NFF is output, though this is easily changed
  101. by changing OUTPUT_RT_DEFAULT in the code.  Also, typing "prog -?" gives you
  102. the options available.
  103.  
  104. The DXF displayer/converter "readdxf" works as follows:
  105.  
  106.     readdxf [-r renderer] filename
  107.  
  108. "-r 0" means display on screen, the others convert, etc.  Two sample models,
  109. skull.dxf and f117.dxf, are provided as examples.  These were created with the
  110. HyperSpace(tm) 3-D digitizing system from Mira Imaging, Inc.  Contact them at
  111. 801-466-4641 (Seth Jarvis) for more information.
  112.  
  113. I've tried to comment to a reasonable extent, but to be sure, you will need to
  114. be reasonably fluent in "C" to make full use of this stuff.  (Or perhaps make
  115. bindings for Pascal & then just use as a library.)
  116.  
  117. Depending on the features or speed of a particular renderer, you can tell the
  118. library code to output primitives in its native format.  The "sample.c" file
  119. has a simple scene, which can now be output in any supported format.  I have
  120. found this code to be very useful for generating frames for animations from
  121. "C" programs.  All you need to do is open a file for output, generate the
  122. database, and then use a "system" call to perform the render.  There are three
  123. other sample procedural model generation files, "lattice.c", "shells.c", and
  124. "sombrero.c".
  125.  
  126. In addition to the sphere, polygon, and cylinder/cone objects that were
  127. supported in the original SPD, support has been added for:  boxes, tori,
  128. height fields, and superquadrics.  For those raytracers that do not support
  129. these as primitives, the output will be a large number of triangle patches.
  130.  
  131. As far as video output goes, a couple of simple display driver files are
  132. included:  "mac.c", "ibm.c", "hp.c", "disp.c".  These are enough to make
  133. things work, but aren't meant to do much more than that.  If you wish to add a
  134. new display engine for a new machine type not mentioned here, you will need to
  135. create a new file and define the following functions:  display_init,
  136. display_close, display_clear, display_plot [actually, currently not used], and
  137. display_line [which is a little peculiar, see unix.c for details].  There is
  138. also a routine kbhit() for allowing display interrupt from the keyboard, if
  139. needed.  If you don't have access to display drivers for your machine, simply
  140. compile with "unix.c" - all display calls will then be ignored.
  141.  
  142. Oh, yeah - the coordinate system used in this library is left-handed.  This
  143. may seem backwards for those of you used to one renderer vs another, but it is
  144. simple enough to change:  always negate the value of just one of the
  145. coordinates and you get right-handed coordinates.
  146.  
  147. (Try "gears" for a real CPU eater)
  148.  
  149. If you wish to reach the people who tweaked this stuff, we are on Compuserve
  150. (E-Mail, or in the GRAPHDEV forum) as:
  151.  
  152. Alexander Enzmann
  153.   CIS: 70323,2461
  154.   internet: xander@mitre.org
  155.  
  156. Eduard Schwan
  157.   CIS: 71513,2161
  158.   internet: 71513.2161@compuserve.com
  159.  
  160. The original author, Eric Haines, is at erich@eye.com.
  161.  
  162.  
  163. Post-it Notes
  164. -------------
  165.  
  166.    - POV-Ray does not support arbitrary polygons, you get lots of triangles
  167.    - RTrace does not support Phong highlights separately from reflections. It
  168.      is difficult to get RTrace surfaces to look like other renderers
  169.    - Polygons in PLG format will typically need to be scaled way up.
  170.    - Rayshade if compiled right out of the box won't take CR/LF pairs in files,
  171.      end of lines must be a single LF.
  172.    - QRT has bad refraction code and doesn't support arbitrary polygons
  173.    - The Macintosh programs require at least System 6.0.4, and run just
  174.      fine under System 7 & 7.1.  They also need a 68020 CPU, but do not
  175.      require an FPU.  And for some of the larger runs, they may need 2 or
  176.      3 mb of application heap space.  So they should run fine on LCs and
  177.      powerbooks, given enough RAM and disk space!
  178.  
  179.